NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/5530

Internet Message Format | 1996-08-05 | 4.8 KB

Path: dawn.mmm.com!news
From: [e-mail] (Kevin J Hopps)
Newsgroups: comp.lang.c++
Subject: Re: How to handle error in constructor
Date: 5 Feb 1996 14:16:48 GMT
Organization: 3M - St. Paul, MN  55144-1000 US
Distribution: world
Message-ID: <4f53gg$[e-mail]>
References: <4eo6n6$[e-mail]> <1996Feb2.170821.1768@ittpub>
Reply-To: [e-mail]
X-Newsreader: TIN [version 1.2 PL2]

Wil Evers ([e-mail]) wrote:
WE> In article <4eo6n6$[e-mail]> [e-mail]
WE> (Mickey Williams 66753) writes:
MW> In article [e-mail],  [e-mail] (Andrew
WE> Phillips) writes:

AP>I'm converting and enhancing a simple program in C to C++. Without
AP>going into too much detail I have a class that represents a file on
AP>disk. The contructor opens the file, but what should it do if the file
AP>cannot be opened?  The C program just calls fopen() tests the return
AP>value and if there's an error it prints a message and exits.

AP>In C++ I thought to set a flag in the constructor and have a member
AP>function that tests the flag to see if the file was opened correctly.

MW> In practice, it is impossible to ensure that this works as intended.
MW> Also, every user of this class must understand this error handling
MW> mechanism. On the other hand, exceptions are part of the standard, so
MW> throwing one of the standard exceptions should be much safer.

WE> There may be alternatives to throwing an exception here. Basically, disk
WE> file objects should behave reasonbly when the constructor couldn't open
WE> the requested file: for instance, instead of just assuming the fopen()
WE> succeeded, they could report failure when someone tries a read or write
WE> operation.

AP>This seems rather inelegant -- I guess exceptions would be the elegant
AP>way but seem like overkill for such a simple program.

MW> Elegant, schmelegant. It's the correct tool for the job.
MW> [example deleted]

WE> Is it? Suppose, for instance, that I want to check for some parameter
WE> settings in an optional configuration file. Here, all I need to know is if
WE> there are any options to set. If there are none, I don't care why, so if
WE> the first read on the non-existing file simply returns EOF, I will be
WE> perfectly happy.

Whether a given function should be written to throw an exception or indicate
failure in some other way depends largely on what would be convenient for its
callers.  If, for most of them, failure of the function means failure for them,
an exception may be best.  If, OTOH, failure of the function is of little
consequence, a simple return code might be best.

Deciding how to report an error from a function whose users are unknown can
be a problem.  One pretty much has to guess what the users will want.

It does not seem appropriate to fail silently.  This is what constructors
and overloaded operators must do if they do not throw an exception on
failure.

WE> If the disk file class further provides me with the option of telling me
WE> if the file could be opened - and, if not, why not, then I can decide for
WE> myself how sophisticated my error handling will be.

WE> The problem with exceptions is, that I'm *required* to handle them or else
WE> my program will die - even if failure to open a file is nothing to be
WE> upset about. A decent disk file class should at least give me the option
WE> to say 'no thanks, no exceptions for me this time.'

Regardless of whether you're using exceptions or indicating errors in
traditional ways like return codes, you can ignore errors or handle them.
The differences are in what happens by default, and in when the errors are
reported.  You can ignore return-codes very easily, but you can't use them
from constructors and overloaded operators.  You can ignore exceptions too,
but you have to write extra code to do it.

Personally, I like the idea of being *required* to handle errors, even if
that means consciously throwing them away.

WE> IMHO exceptions are useful for handling major disasters, not for small
WE> inconveniences. Classes simply throwing an exception from their
WE> constructors because the class's programmer is too lazy to keep the
WE> object's state consistent in the face of such a failure are a nuisance at
WE> best, and could easily cause severe paranoia for the class's users.

A certain amount of paranoia with regard to error handling is a good thing,
IMHO.  I think many programs would be much more robust if they were developed
with a little more paranoia about errors.
--
Kevin J. Hopps                  e-mail: [e-mail]
3M Company                      phone:  [phone]
3M Center, Bldg. 235-2D-57      fax:    [phone]
St. Paul, MN 55144-1000         Opinions are my own.  I don't speak for 3M.
    But 3M speaks for me -- I did not write the following line:

Opinions expressed herein are my own and may not represent those of 3M.